====================================================================== IBIS INTERCONNECT MODELING AD HOC TASK GROUP MEETING MINUTES AND AGENDA http://www.eda.org/ibis/adhoc/interconnect/ Mailing list: ibis-interconn@freelists.org ====================================================================== Next Meeting Wednesday, May 6, 2009 8 AM US Pacific Time Telephone Bridge Passcode 916-356-2663 1 312-7110 (for international and alternate US numbers, contact Michael Mirmak) LiveMeeting: https://webjoin.intel.com/?passcode=3127110 Agenda: - Call for patents - Opens - Review of parser requirements document ====================================================================== Minutes from April 29: Attendees: ---------- (* denotes present) Agilent - Radek Biernacki, John Moore, Ken Wong Ansoft - Denis Soldo Cadence Design Systems - Terry Jernberg, Brad Griffin Cisco Systems - Mike LaBonte* Green Streak Programs - Lynne Green Hewlett-Packard - Rob Elliott Intel - Michael Mirmak* Mentor Graphics Corp. - John Angulo, Vladimir Dmitriev-Zdorov* Micron Technology - Randy Wolff Sigrity - Sam Chitwood, Raymond Y. Chen, Tao Su, Brad Brim SiSoft - Walter Katz* Teraspeed Consulting Group - Bob Ross* ======================================================================== No patents were declared. Michael presented a brief list of proposals and questions regarding development of a Touchstone 2.0 file parser. Bob expressed support for complete Touchstone 2.0 only checking in any parser to be developed now, with comprehensive 1.0 checking later, because of column/formatting and other consistency issues. Touchstone 1.0 file compatibility is not an industry issue anymore. Mike LaBonte asked why the parser should not check 1.0. Michael Mirmak responded that we would rapidly encounter issues with reading rules not followed or widely understood by industry but spelled out in the official documents (e.g., options order). Mike asked whether a parse-and-discard structure would be appropriate for 1.0. The parser would have to read information from a 1.0 file and put it into memory. Bob responded that this could be done without syntax checking. Mike thought some level of checking is required for 1.0. His proposal: the only error messages to be printed for 1.0 are ones related to any inability of the parser to read data into memory structures. Bob and Mike agreed that syntax is the first checking priority. Mike added that units may be a problem in some cases. Assumption of pF instead of F helps with range checks. Mike stated that the easiest requirement on the parser is simply leaving items in the specification as the only guidance. Bob suggested a line-by-line spec reading as the most reasonable way to develop the parser architecture. Perfection is not the goal. Mike noted that errors/warnings/notes/cautions similar to the IBISCHK5 approach should be supported. Bob added that mis-matching the number of frequencies vs. ports vs. all data available is error, as is a missing [End]. Warnings are more subjective, as are cautions. Warnings may get ignored if too numerous. Mike responded that, with a syntax-only checker, everything wrong is an error. The sanity checks are what generate the warnings, cautions, etc. The parser shouldn't force depend on a particular numbering system. Mike added that parser data structures should be left up to the parser developer (really up to tool developers as well). Vladimir suggested making some concrete proposals in that direction, including limiting the number of different structures (real and imaginary only; no support for mag./angle in actual data structures, etc.). The parser doesn't need to support all representations in the tools. He added that he would define anything that prevents reading the data up to the point being parsed is an error. Negative magnitudes are errors, as this wouldn't fit a data structure, but a negative resistance is a warning, because we can read and use it mathematically. Mike suggested passing data by callback, to save memory, with the parser not storing everything in memory. Walter responded that tool vendors will likely write their own parsers. Some checks may require no memory at all but keep in mind that files can be very, very large. Mike suggested that the document may state that data structure parsing is optional, but the writer should watch out for memory allocation. Both Bob and Mike agreed the parser should be command-line-based. Mike added that a UI is optional. As to language, Vladimir noted that if transformation is in the parser, then it makes sense to integrate the parser into software tools (mixed mode into standard is the most painful conversion). Bob suggested that any parser be accessible at a command-line and must be portable; The format is the developer's choice. Walter added that, if the parser is integrated with a tool, the language is likely to be C. Michael will prepare a draft parser requirements document for review next week.